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OVERVIEW 


This paper addresses concepts for vehicle and payload avionics architectures 
for future NASA programs, including the Assured Shuttle Access program. Space 
Station Freedom (SSF), Shuttle-C, Advanced Manned Launch System (AMLS) , and 
the Lunar/Mars programs. Emphasis Is on the potential available to Increase 
payload services which will be required In the future, while decreasing the 
operational cost/complexity by utilizing state of the art advanced avionics 
systems and a distributed processing architecture. Also addressed are the 
trade studies required to determine the optimal degree of vehicle (NASA) to 
payload (customer) separation and the ramifications of these decisions. 

MAJOR OBJECTIVES 


The avionics payload support architecture for future NASA space programs Is 
designed to meet several major objectives. The typical customer vehicle 
avionics requirements Include reliable provision for command, telemetry, 
video services, onboard data storage capability, and the capability to access 
vehicle data (e.g., attitude, state vehicle, timing, etc.) through some sort 
of "gateway". The extent and requirement for these services depends upon the 
type of payload (deployable, attached, scientific experiment, etc.) and the 
type of mission (e.g., short versus long duration). A deployable payload 
which only resides In the NSTS orblter for a few hours on-orbit typically 
requires different services than will attached SSF scientific experiments. 

From the NASA budgetary perspective. It Is important to utilize an avionics 
payload support architecture which reduces the labor Intensive Integration, 
flight to flight reconfiguration process, mission operations support and 
crew/controller training. 

In order to accomplish this. It is desirable to reduce the Interdependence of 
the vehicle and payload where practical. By selectively designing the 
payload architecture to Include a separate distributed payload data 
management system. Including separate data storage as well as processing 
equipment, the payload capabilities are not limited by competition with the 
vehicle's requirements and the payload schedule Is not tied to a mature 
vehicle's reconfiguration schedule. (See figure 1.) It would also be 
desirable to have a separate uplink and downlink capability for the same 
reasons as outlined above. This capability may be more of a cost Impact and 
must be weighed as such. 

An additional consideration In the design of the avionics payload support 
architecture Is the utilization of government or Industry standards such as 
the 80386 processor, the 1750A processor, the 1553 data bus, etc. This will 
enhance the budgetary aspect of the program by allowing the use of commercial 
off-the-shelf (COTS) hardware and software, as well as providing the customer 
with standards for their design and software development that match those 
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available on the open market. Additionally, a customer could then transition 
easily from host program to host program (e.g.. Shuttle to Space Station 
Freedom) without major electronic redesign. Other benefits to this approach 
would be derived If the system was designed to allow provision for program 
Interchangeability of components and the capability to easily upgrade the 
system as new capabilities are developed. 

MAJOR MILESTONES 

The concept of the use of a distributed avionics support architecture for 
payload applications is not a new one. It was proposed in the 1970's during 
the design phase for the NSTS orblter. It was not Implemented due to 
philosophical and budgetary considerations. As a result, the STS currently 
assumes an Increased cost for payload reconfiguration flight to flight, does 
not provide sophistication in payload software control, provides minimal 
payload data storage capability, provides only minimal vehicle data to major 
payloads, and provides no vehicle avionics services to the scientific 
experiments flown In the middeck. In order to alleviate some of these 
concerns, and with the advent of the microcomputer technology, the STS is now 
providing customers with the option of using the STS payload and general 
support computer (PGSC), which is a modified GRID 1530. The STS-provided 
PGSC is flight qualified. Its utilization is under configuration control by 
the STS relative to the user interface. This insures standardization in 
order to reduce crew/ground training and simplify procedure development. The 
Interface Control Document (ICD) and user guidelines for the PGSC were 
published in 1989 and the system flew on STS- 30 and STS-34 for the Fluids 
Experiment Apparatus (FEA) and Polymer Morphology (PM) payloads, 
respectively. Numerous other payloads have requested its use. Most notable 
is the Tethered Satellite System (TSS). 

The PGSC does not directly have a link to the orblter communication system 
which limits ground control of experiments. This, in turn, potentially 
limits scientific return from payloads and also places a greater burden on 
the fllghtcrew (training and timeline impact). In some applications, such as 
TSS, this is overcome by use of the STS smart flexible 
multiplexer/demultiplexer (SFMDM) which Is connected to both the orblter 
communications system, as well the PGSC. 

Another major milestone toward the recommended payload support architecture 
was the original SSF payload support architecture definition. It Included a 
distributed processing architecture, standardized testing, checkout, and 
training, and, In general, a decoupling of vehicle and payload services. 
Unfortunately, the 1989 budgetary scrub exercise resulted In the potential 
deletion of many of the distributed payload avionics capabilities at the 
Permanent Manned Configuration (PMC) such as a separate payload local area 
network (LAN), separate payload data storage capability, and separate payload 
command uplink capability. It was proposed that this configuration would be 
eventually upgraded with the later full-up configuration. Of concern is that 
the full-up configuration is not funded and will Itself probably be 
confronted with a stringent budget. In addition, the cost and labor required 
to upgrade the system by the astronauts will be time consuming and complex. 

The Shuttle-C payload services definition served as another milestone. 
Although the proposed payload services provided by the Shuttle-C are somewhat 
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minimal. It did propose placing the majority of the payload services 
responsibility on the payload customer and thus simplifying the payload 
Integration and operations costs. 

TECHNOLOGY ISSUES 

Some technology Issues exist for the above mentioned programs. For the STS 
orblter, the Issues and work that are ahead as part of the Assured Shuttle 
Access program Include replacing certain components such as the pulse code 
modulator master unit (PCMMU) /pay load data Interleaver (PDI) due to parts 
obsolescence. This opens the opportunity to enhance the downlink data 
capability as well as provides redundancy in the payload PDI link. Cost, 
schedule Impacts to vehicles in the flow, and compatibility with the orblter 
communications system are Issues being worked In this area. Another Item 
under Investigation Is the replacement of the orblter payload recorder with 
one more suitable to the typical payload's bit rates and data recording 
requirements. Another technology issue relates to the need for further 
advances in connector and cabling design In order to reduce both volume and 
weight. This Is, of course, a concern with all of the programs. Another 
area that needs further work Is to develop a capability, via modem or a 
separate SFMDM type "black box", to provided communication services to 
orblter payloads, such as middeck scientific experiments. 

The major technology Issues for the SSF program, relative to avionics payload 
support architecture, are In the integration of existing avionics 
technologies to control multiple real-time systems and limited vehicle 
resources, such as power, communication, assets, etc. 

The Lunar /Mars programs require more sophisticated avionics capabilities in 
order to meet the expected needs of these payloads over extended periods of 
time and with a greater communication lag between the ground operation team 
(Including scientists) and the vehicle. This will lead to an Increased 
requirement for automation and expert systems capability. In addition. It Is 
estimated that the data storage capability required for some payloads which 
are proposed for the Mars mission would be on the order of 1X10E12 bytes, 
which Is two orders of magnitude greater than what is currently available. 

In addition to this need for increased onboard data storage. It is 
anticipated that there will be a requirement for some level of 
pretransmission data compression for the Mars mission which has historically 
been a concern to the vehicle and scientific communities. 

Another area which warrants further exploration for each of the NASA programs 
is advancement In technology to Increase the operational efficiency of the 
above programs In areas such as automation, robotics, expert systems, voice 
recognition, speaker Independent systems, enhanced video display capability, 
etc. 

TRADE STUDIES 


Perhaps more Important than the technology Issues mentioned above are the 
trade studies that are required to determine the NASA position relative to 
the payload community. The overall concern Is the appropriate degree of 
NASA/user separation. This lies at the heart of many policy decisions 
relative to the handling of payloads. The question concerns the balance of 
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common services provided by the vehicle (NASA responsibility) versus those 
provided by the customer (user responsibility). For example. If the Agency 
were to provide an Industry standard architecture (ISA) processor with 
display capability, an I/O consisting of MIL-ST0-1553B data busses, storage 
medium, and access to vehicle system data via a gateway, should the Agency 
provide the real-time ADA operating system with the application software 
being the responsibility of the user? If so, what Is the interface criteria 
between the operating system and the application programs? Where does the 
responsibility lie between NASA and the customer? Would NASA supply the 
background display structure and the customer provide the dynamic fill to 
reduce and minimize crew training, whether ground or flight? Is there some 
Interface line that can be drawn between host vehicle and user 
responsibilities that is beneficial to both In cost and Integration schedule 
flexibility? If this type of standardization is used (in the example), the 
customer can utilize relatively Inexpensive ground versions of the flight 
hardware for software development, validation, and payload checkout. When 
drawing this "line 1 ', developing a policy, or developing a criteria, serious 
deliberation and consideration should be given to safety ( 1 . e. , when can 
closed loop control not be implemented by the customer), mission success, 
reliability and/or redundancy, minimizing crew training. Integration of the 
cargo complement (l.e., multiple payloads), and data processing security 
(l.e., protection of customer proprietary information). 

SUMMARY/RECOMMENDATIONS 

In summary. It Is Important to keep in mind that the major goal of the 
operational NASA missions Is related to payload/experiment activity, be It 
deployment of a satellite or a long-range scientific experiment. It is 
Important to Insure that the NASA programs provide services to make those 
programs, whether It Is Shuttle-II, SSF, or some advanced upper stage, 
accessible to users. In addition. It Is Important for NASA to make 
responsible decisions In the design of Its programs to Insure that they have 
not cut costs for DOT&E, which will result In Increased costs In the out- 
years that significantly exceed what would have been the Initial DOT&E cost 
Investment. It Is time for the Agency to address commonality between 
programs to reduce DDT&E cost and "redesign the wheel" tendencies. It Is 
equally Important that these designs provide the user a low cost means to 
utilize the host vehicle capabilities without complex, time consuming 
Integration processes, which Is a major complaint of shuttle users. Program 
commonality and simplified Integration processes with respect to payload 
accommodations provides the same cost and labor benefits to the customer that 
could be realized by NASA. Commonality provides options to the user for 
access to space. In simple terms, more programs and more experiments could 
be started, developed, and flown for the same budget. If cross program 
avionics commonality Is imposed In the out years. However, DOT&E monies must 
be expended now to realize such a benefit. 

In order to further pursue these areas, several things must be accomplished. 
Development of a payload/host vehicle policy Is required to distribute 
responsibility, when practical and cost effective, to the user. It may be 
necessary to rearrange these responsibilities based on the type of host 
vehicle (l.e., Shuttle-II versus Shuttle-C). Whatever the result, this 
policy should provide a framework for avionics hardware and software 
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commonality between all host vehicle programs and should delineate the 
separation of responsibilities between host vehicle and user. 

An avionics payload support architecture must then be developed to support 
the resultant policies. Paramount to this design Is addressing 
standardization-use of those Industry or government standards that Impose 
program cross utilization, a means of technology evolution to resolve parts 
obsolescence concerns. The final system should also Include functions that 
minimize the out years operating base, such as built In test and checkout. 

It Is In NASA's best Interest to develop such a payload support architecture 
for use across programs to use new avionics technology to Increase operations 
efficiency and thus reduce recurring operations costs. 
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Figure. Example of a Proposed Advanced Avionics Payload Support Architecture 
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